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The 

RICIS 

Concept 


The University of Houston-Clear Lake established the Research Institute for 
Computing and Information systems in 1986 to encourage NASA Johnson Space 
Center and local industry to actively support research in the computing and 
information sciences. As part of this endeavor, UH-Clear Lake proposed a 
partnership with JSC to jointly define and manage an integrated program of research 
in advanced data processing technology needed for JSC’s main missions, including 
administrative, engineering and science responsibilities. JSC agreed and entered into 
a three-year cooperative agreement with UH-Clear Lake beginning in May, 1986, to 
jointly plan and execute such research through RICIS. Additionally, under 
Cooperative Agreement NCC 9-16, computing and educational facilities are shared 
by the two institutions to conduct the research. 

The mission of RICIS is to conduct, coordinate and disseminate research on 
computing and information systems among researchers, sponsors and users from 
UH-Clear Lake, NASA/JSC, and other research organizations. Within UH-Clear 
Lake, the mission is being implemented through interdisciplinary involvement of 
faculty and students from each of the four schools: Business, Education, Human 
Sciences and Humanities, and Natural and Applied Sciences. 

Other research organizations are involved via the “gateway” concept. UH-Clear 
Lake establishes relationships with other universities and research organizations, 
having common research interests, to provide additional sources of expertise to 
conduct needed research. 

A major role of RICIS is to find the best match of sponsors, researchers and 
research objectives to advance knowledge in the computing and information 
sciences. Working jointly with NAS A/ JSC, RICIS advises on research needs, 
recommends principals for conducting the research, provides technical and 
administrative support to coordinate the research, and integrates technical results 
into the cooperative goals of UH-Clear Lake and NAS A/ JSC. 
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INTERNAL 

MEMORANDOM 


29 May 1987 


To: Dr. Jani 
From: Bill Othon 

Re: Implementation of Vision Sensor algorithms received from 
Rice University 


I have looked over the first package of C-language routines 
received from Rice. The package includes 12 routines involved in 
wireframe construction and identification. Also, there is code 
which defines two wireframe objects, a ball and a box, and data 
files associated with the C files. 


A driver routine was included in the files to run many, but not 
all, the 'vision' routines. The driver called the following 
routines: 


1) transfor.c: rotates and translates a given wireframe object. 
The rotation and translation parameters are user-input, and the 
object is defined in ‘ database. c ' . The input object is changed, 
but the original orientation is still available in ' database. c' . 

2) wiredraw. c: draws a 2D image of a given 3D wireframe object 
on a tektronics-like terminal. Hidden faces are identified by 
evaluating the y-component (perpendicular to image plane) of the 
points making up a given face. If the y-component is larger than 
a certain set value, the face associated with the point is 
defined as not visible. 

3) wiregnr.c : converts a 3D wireframe object into a 2D image 

which is a projection of the original (rotated) object. Again, 
non-visible faces are determined and not included in the image. 
The total number of visible faces and edges is determined, and 
edge connectivity among the faces is defined (ie. if two faces 
share an edge, variable = l, else variable * 0). 



4) obinit.c : calculates the relationship between the faces 
of the original rotated object. Calculates angles between the 
normals of the faces, and the moments, invariants, and tensors of 
each face. This information is stored in the object data 
structure. 

5) owmatch.c : conducts the actual comparision between the 
predefined 3D object in the database and the 2D rotated image of 
the object. For each face on the object, the moment invariant of 
the object face is compared to the moment invariant of a given 
face of the 2D image. If the invariants are sufficiently close 
(arbitrary) , the object and image faces are input to the 'grow' 
subroutine, the heart of the comparison process, •grow' is a 
recursive routine which tries to match the input faces (or root 
faces) with their surrounding, adjecent faces. In other words, if 
both the object root face and image root face are surrounded by 
the same faces (as determined by the algorithm) , the image is 
assumed to be a subgraph of the object. The output of the 
subroutine is just a (match/no match) . No orientation 
identification algorithms have been identified. It may be 
possible to reverse the role of the transform subroutine, so 
instead of using user-input parameters to get a transformed 
object, these parameters may be backed out from an image. More 
work is being conducted to fully understand the comparision 
procedure. 


These programs represent all the algorithms used by the driver 
routine. It seems that the purpose of this driver is to varify 
the ability of the comparision algorithm to successfully identify 
a known object. 


Two other programs were included in the software package, 
‘ipc.c' and 'gipc.c' are the image point coorespondance routines, 
defined by a paper authored by Rice's Sunil Fotedar and Dr. Rue 
de Figueiredo. These routines are used in the determination of 
motion parameters of a moving object from moving camera data. 
The documentation identifies a number of case options and 
associated algorithms involved in the operation of these codes, 
but these files were not included in the package from Rice. 


What I plan to do in the short term is remove the wireframe 
building routines from the driver code and run the program 
without graphics, to see if it works. Actually, the graphics 
associated with the driver are for display purposes only, and 
input no information to the driver routine. 

Apparently, we still need to receive algorithms which can read a 
2D image (from graphics) and can convert the image into a form 
which can be used to compare it to models in the object library. 
Also, we need to find out which algorithms should be used to 
calculate the orientation of an object, once the associated image 
has been identified. 

Attached to this memo is information on each of the routines 
delivered by Rice. 
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'he object tiles* ail routines* shown here Percept for driver routines) 

ire kept in an archive library / mnt /bami eh / c 1 eanpr o j / 1 3 b . This 

lame should be used in the? with the? cc comsnd. 

ill routines were compiled with the -g option for debuging. 


*****■*■#•■*■*- 


amieh.h : This file contains* all the headers used. It contains 

type definitions, and also stdio and math.h. In this 
directory it is used by ^include "bamieh.h". 


atabase.es The database which contains the initial object 

d 1 scr i tpt i ons , New objects are added here. An object 
is declared as an extern polyhedron variable, and 
any programs that use the object should be compiled 
and linked to the database. 


~ansform.es contains the routine 

pol yhedron transf orm (dx , dz , theta , phi , psi , object ) 
f 1 oat dx , dz , theta, phi , psi ; 
pol yhedron ob j ec t ; 

which rotates and translates a polyhedron "object " 
in 3-space by transforming the coordinates in 
the array vert[] , the other parameters of a polyhedron 
are i nvar i ant . 

dx,dz s translation in the x and z axes respectively. 

theta, phi: spherical coordinates of the axis of rotation 

theta is the angle in the x , y plane. 

psi : the magnitude of the counterclockwise rotation 
about the axis. 

object s the structure containing the polyhedron. 

all angles should be in degrees, transform returns 
a polyhedron structure which is the rotated object. 


r aw.cs Contains the function 

hdr aw (hof f set , vof f set , wndsi z e , ob j ec t ) 
i nt hof f set , vof f set , wnds ire; 
piol yhedron ob ject ; 

which draws a polyhedron “object" on a tek.tr onix 
like- terminal, assumina o^thoaonAl nm 1 
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y a- j s a t the x , r image plane. 

The tcrtpii Dnain it at the lower left- 
hand corner, the? vertical and horizontal scales are 
799 and 1024 respectively. The object is dr awn in a 
square window specified by the -following parameters: 

hot f set , vof f set : the horizontal and vertical coordinates 

of the wi ndow origin, respectively. 

wild size : the length of the* window side. 

This routine does hidden line removal for a convex 
ob _iect , 


draw. c : Contains 

draw . c <hof f set , vof f set: , wndsi ze , ob jec t ) 

Same as hdraw but does not do hidden lines. 


jo 1 ymn t s . c 


Cental ns 


pol ygon2 pol ymnt s (face) 
palyqon2 face; 

which calculates the moments of a 2D polygon "face" 
and returns the same 2D polygon but with the 
moments entries appropriatly filled. The highest 
order of moments calculated is determined by 
MORDER in the file bamieh.h, this constant also 
effects the type defeni tions. 


war l an t s . c : Lon t ai n s 


pol ygoriL i n van ants (face) 
polyqan2 face; 

which calculates the invariants given the moments 
which should already be in face. It returns the 
original 2D polygon face with the invariants in 
thei r proper p 1 aces . 


*nsor.c Contains 

f 1 oat Ttensor (face , i ndex ) ; 

polyqon2 face; int index; ORIGINAL PAGE IS 

f 1 oat Vtensor (face , i ndex ) ; 0F P0 °R quality 

polygon2 face; int index; 

which calculates the tensors T and V (see paper). 

Index specifies which component of the tensor is to be 
calculated, either 1 or 2. 

These tensors are calculated in the most brute force 
way imaginable, if they become a bottleneck, they 
probably can be i mproved substanti al y . 





Cont a 1 ns 


wire-frame- wimt (immsp' /* wire-franie initializer * / 

wi re-frame 1 mmap ; 

Ira ti ali res wireframe by symmet r i r i no the edqes matrix. 
It also adds the moments invariants and tensors of every 
-face in the wi r e-f r ame. The original wireframe plus every 
thing added is returned. 


ibi mt.c Contains 

polyhedron obi ni t (object ) ; /* object initializer */ 

pal yhedron object ; 

Intitializes the object by symmetrizing the? edges matrix 
and adding the moments, invariants, and tensors to every 
face. These last there are computed in the plane in 
which each face lies. 

The initialized object is returned. 


l r eg nr : Cont a 1 ns 

wireframe wiregnr (that a, phi ,psi , object) 
float theta , phi , psi ; 
pol yhedron object ; 

which genterates a wireframe of a polyhedron "object" 
viewd with a rotation of thet a , phi , psi . The function 
returns the wireframe it generates. To find the visible 
faces it basically uses a code similar to that of hdraw, 
except that faces that are only very slightly visible 
(i.e. almost perpendicular to the image plane) are not 
included in the wireframe. 


redraw. c ; 


Cont ai ns 

wi redraw (theta , phi ,psi , object) 
float thet a, phi, psi; 
pol yhedron object : 

This is similar to hdraw except that it draws the 
object exactly as the wireframe generator “wiregnr" 
sees it, i.e. faces that are only slightly visible 
are not included. The arguments are the same as hdraw. 


match. c: Contains "object to wireframe matching" 

correspondence owmatch ( object , 1 mmap) ORiGjflAL PAGE IS 

polyhedron object; OF POOR QUALITY 

wi ref r a me i mmap; 

which looks for a possible match between the object and 
a wireframe. The results of the match is returned as a 
cor r espondence struct . 


iTitest . c 


A driver routine. S e- 1 { e- >. planet or y. 
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Simulation of Robotics Space Operations 

Principal Investigator* Yashvant Jani 
LinCom Corporation 

Computer-based simulations of activities in low earth orbit 
play a vital role in the research and development of space 
missions, especially generation scenarios. In order to 

successfully plan and analyst future space activities, these 
simulations will be required to model and integrate vision and 
robotics operations with vehicle dynamics, and proximity 

operations procedures. The basic objective of this project is to 
configure and enhance the orbital operations simulation (OOS) as 
a testbed for robotics space operations. 


The vision sensor is comprised of many subsystems, which 
will? 1) Detect the presence of orbiting space vehicles, using 
camera data, 2) Identify an unknown vehicle being scanned by a 

camera, 3) Identify the position, attitude, and rates of a 

* 

scanned object, and 4) Track a vehicle along its flight path. 

Each of these capabilities could be used for a wide range of 
orbital operations, including proximity operations of vehicles, 
traffic control, and collision avoidance. Additionally, the 
vision sensor when integrated with robotics, would allow 
robotics-enhanced, free-flying vehicles, like the Orbital 
Maneuvering Vehicle (OMV) , to conduct autonomous missions 
including vehicle repair and retrieval. By using the vision 
sensor, autonomous vehicles could identify desired targets, track 
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their motion and attitude, and dock with the target. The vision 
sensor could also identify damage, and provide visual data 
required for work with Remote Manipulate System (RMS). 


The 

vision 

sensor 

will be 

mathmatically modeled. 

and 

included 

in a 

general 

orbital 

operations simulator. 

• By 


coupling the vision sensor with vehicle dynamics and the orbital 
environment, the simulation will be used as a test-bed for the 
development, and optimization of vision-related operations 
procedures. The simulation can use a number of different orbital 
vehicles during testing of vision techniques, including shuttle, 
OMV , and eventually Space Station. Topics that can be explored 
through simulation include range requirements, resolution 
constraints, data extraction and analysis techniques, and 
integration of vehicle flight software and vision-derived 
environment and tracking information. 

*The vision data processing algorithm will be implemented as a 
flight software which can be scheduled according to the 
processing requirements. 
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MEMORANDOM 


1 August 1987 


To: Dr. Jani 
From: Bill Othon 

Re: Status Update of Implementation of Vision Sensor algorithms 


While I was on leave, the complete code for Rice's GIPC (motion 
parameter determination) and MIAG (object identification) 
algorithms were delivered to LinCom. The GIPC code includes a 
small menu and algorithms for all methods of motion determination 
outlined in the reference document. The MIAG also includes a 
menu for user input. A number of object models (with vertex, 
face, and edge information) were included for testing. 

These codes are currently being examined and evaluated for 
modifications which would be necessary before inclusion into 00S. 
David and I intend to get the stand-alone versions of these codes 
running, and to test output from the code with available 
reference material. Thus, we can be sure the code is running 
correctly before integration with 00S. 

One small note: Apparantly, the computer hardware at Rice has 
different capabilities and resources than the HP9000 at LinCom. 
Consequently, the two algorithms are not running smoothly at this 
time. Some of the arrays in the GIPC routine are dimensioned 
arbitrarily large, and may be overwriting memory. This problem 
is currently being examined. 


August 11, 1987 



SIMULATION OF ROBOTICS SPACE OPERATIONS 


STATUS OF INTEGRATION OF VISION ALGORITHMS INTO OOS 


AUGUST 11,1987 


MEETING WITH VISHAL MARKANDEY, RICE UNIVERSITY- 7/30/87 

Dr. Yashvant Jani and William Othon met with Vishal 
Markandey of Rice University on 7/30/87. Vishal brought with him 
graphics algorithms for extracting wireframe and vertex 
information from the image of an object, produced by a camera. 
These routines were not fully completed, and development and 
modification of these algorithms continues at Rice. However, 
LinCom will begin analysis of the routines for future integration 
into 00S. 

A copy of a single value decomposition (SVD) routine was 
given to Vishal at the meeting. David Myrick translated this SVD 
routine from FORTRAN listing to ' C' code. The translation was 
necessary because the routine was not available to LinCom, and it 
was part of a prepackaged math library at Rice which could not be 
transferred. The routine is used in the Generalized Image Point 
Correspondence (GIPC) algorithm, which extracts motion parameters 
of a moving object from information provided by a moving camera. 


THREE MAIN AREAS OF VISION ALGORITHM DEVELOPMENT 


Vishal described the three main areas of vision algorithm 
development going on at Rice. The three main areas are: 1) 
preprocessing of raw camera (pixel) data, 2) object recognition 
from preprocessed data, and 3) determination of the attitude and 
attitude rates of a observed object (figure 1) . 

1) Preprocessing 

Preprocessing algorithms transform the raw camera pixel data 
of a scanned object into a graphical representation of the 
object. This representation can then be used by other vision 
algorithms to identify the object and define its position and 
attitude. There are several elements to the preprocessing phase: 


NOISE REMOVAL- Every frame taken from a camera in pixel 
format will have noise which is unassociated with the object 
being scanned. This noise can be filtered out based on the 
abruptness of the change in "gray-level", or intensity, of the 
pixels. If this gray-level change is sufficiently abrupt from one 
pixel to the next, and there is no continuity in intensity, the 
pixel is defined as noise and filtered out. If the intensity from 
one pixel to the next is continuous, or changing gradually, the 
pixels are assumed to be part of the pictured object. A gaussian 
filtering routine is used to remove the high frequency noise 
(i.e. abrupt, non-continuous change in pixel intensity). 

REGION GROWING- Some of the characteristics of an object, 
such as writing, emblems, or windows, are interpreted as polygons 
by the vision algorithms. These polygons appear as dark regions 
inside lighter areas. To prevent these polygons from being 
identified as faces, a region growing technique is used. Region 
growing increases white areas of the image, but the shape of the 
region is maintained. As the routine continues through more 
iterations, the shape of the image becomes more uniform. 
Eventually, windows and writing are erased from the image. The 
transformed image is larger, but the shape is maintained so that 
identification and attitude can still be determined. 

EDGE DETECTION- Edge detection involves the building of a 2D 
wireframe based on the image of the sighted object. This building 
can be done using vertex detection schemes (after identification 
of straight lines) or contour following (to define object faces) . 


Both schemes use changes in gray-level to define lines or faces. 
After edge detection, the image is transformed into a wireframe 
image, with two levels of intensity: background and the lines of 
the object. 

GRAPH BUILDING- This is the final step in preprocessing. The 
various faces and vertices of the wireframe image are defined and 
stored in a GRAPH STRUCTURE. The moment invariants of the 
identified faces are then calculated. Together, the graph 
structure and the associated moment invariant information are 
known as the ATTRIBUTED GRAPH. 

2) RECOGNITION 

After defining the various components and invariants of the 
wireframe image (whether through simulation or real camera data) , 
the image can be identified with an object in the object library. 
The Moment Invariant/Attributed Graph algorithm (MIAG) matches 
the moment invariants of the wireframe object with those of a 
specific object in the object library. Since these moment 
invariants remain constant for a given polygon, regardless of 
rotations, wireframe polygons and object faces can be compared 
and possible matches identified. Once the possible matches are 
found, then the relationships between the "root" face and 
adjacent object faces and the "root” polygon and adjacent 
wireframe polygons are checked. If all adjacent faces and 
polygons match, the wireframe image is defined as a subgraph of 
the object, and therefore identified. Otherwise, a new object 
from the library can be tested or the matching process stopped, 
(see figure 2) 

Currently, only polygonal shapes can be identified. A future 
extension to the MIAG should allow for edges of various shapes: 
circular, elliptic, etc. To do this, the graph structure must 
have information about the connectivity of faces, and information 


about the contours of connected faces. 


3) ATTITUDE/ ATTITUDE RATES 

Currently, two algorithms are under development for 
determination of attitude and attitude rates based on processed 
camera data. These algorithms are based on different schemes, and 
no comparison of efficiency, accuracy, or speed has yet been 
made. 

The MIAG algorithm calculates tensors based on polygon 
geometry. These tensors can be used to calculate the change in 
attitude between an identified camera image and an object in the 
library (at some reference attitude) . Also, an estimate of the 
translation vector can also be determined. For information about 
the algorithm, refer to "General Moment Invariants and Their 
Application to 3D Object Recognition from a Single Image" by 
B. Bamieh and Prof. Rui de Figueiredo. 

The second method of attitude extraction under development 
is called Generalized Image Point Correspondence (GIPC) . The 
algorithm determines the rotation and translation (to a scale 
factor) of a moving object in some reference frame, from data 
provided from a moving camera. The routine requires: 1) 8 or more 
unique points defined on the object, before and after motion, 2) 
the transformation between the two image coordinate frames, and 
3) the transformation between the original image coordinate frame 
and the reference frame. This method is explained fully in the 
reference "Determination of Motion Parameters of a Moving Object 
From Moving Camera Data" by S. Fotedar and Prof. Rui de 
Figueiredo. 


CAMERA MODEL INTEGRATION IN OOS 

A software model of an OMV-based camera is being developed 
at LinCom. This model will simulate the sensing capabilities and 
hardware constraints of a camera. Characteristics of the camera 
model will include range, field of view, and focal length. 
Additionally, the camera will be integrated with a target- 
tracking algorithm, to define the motion of a camera with two 
gimbals (pitch and yaw) . 

The camera model will be used in simulations where the two- 
dimensional image data is simulated and not derived from actual 
camera input. The translations and rotations of the target (i.e. 
camera image) will be fed directly from the dynamics routines to 
a transformation routine. This routine will transform a library 
model of the target (at some reference orientation) and define 
the points which are visible on the 2D camera image. These data 
can then be fed to the other vision algorithms for object 
identification and determination of motion parameters. 


CURRENT STATUS OF VISION INTEGRATION WORK AT LinCom 


* The SVD routine has been translated from the FORTRAN listing 
to 'C' code. The output was validated. An interface was created 
between the new SVD and OOS-compatible code to be used with GIPC 
algorithm. 

* GIPC and MIAG codes received from Rice are currently being 
tested. Comparison checks are being run between reference 
document data and output from LinCom code. 

* The GIPC 1 C ' code is being modified to match 00S code 
conventions . 

* Integration of validated GIPC and MIAG into vision subsystem 
structures in OOS is being developed. Also being developing is a 
camera model, with hardware restrictions (i.e. range, viewing 
cone, etc.) and target-tracking ability. 

* The preprocessing algorithms delivered by Rice (7/30) will be 
analyzed. Future plans include integration of these vision 
algorithms (in OOS) with graphics for data retrieval and visual 
depiction of vision techniques. 
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LinCom Corporation 
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1 . Introduction 

The Vision program supplied to LinCom by Rice University has 
been modified for use in the Orbital Operations Simulator. This 
required LinCom to add a "singular value decomposition" (svd) 
routine to its library. Also, several changes were made to the 
Vision program itself (see Reference 1). The orginal program 
invoked LINPACK routines. The program was changed to used 
LinCom’ s linear algebra routines. To allow use of the OOS’s 
logging functions and other routines, the program’s array 
structure was changed although it was kept conceptually the same. 
The end result is a cleaner program that is 00S compatible. 
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2. Singular Value Decomposition Algorithm 


The Vision algorithm requires a singular value decomposition 
routine. Rice invoked a LINPACK routine which is part of their 
computer library. Unfortunately, LinCom’s library was lacking in 
an svd routine. A LINPACK svd routine written in FORTRAN was used 
as a basis for LinCom’s svd. This required that the program be 
converted from FORTRAN to C. This conversion proved to be quite 
tedious due to the unstructured nature of the original program. 
Some of the problems encountered included the passing of two- 
dimensional arrays to subroutines expecting one-dimensional 
entities, unstructured usage of GOTO statements, and mathematical 
manipulations of array indeces which had to be changed to meet C 
array conventions. 

FORTRAN and C store arrays differently. Since some routines 
pass two-dimensional arrays to routines expecting one-dimensional 
arrays, a direct conversion was not possible. The Orbital 
Operations Simulator, which is written in C, stores all arrays 
one-dimensionally . Multi-dimensioned arrays are conceptually 
stored columnwise, as in FORTRAN (see Fig. 1). Actual C storage 
is done rowwise. Since FORTRAN stores multi-dimensional arrays 
columnwise and the 00S conceptually stores arrays columnwise, 
svd was converted to store arrays conceptually columnwise. This 
is done in the following manner: 

*[i][j] = x[ i ♦ J * Row_dimension_of_x ]. 

The advantages of singly-dimensioning arrays may not be 


2 


:1!2!3!4!6!6!7|8J9! 

Actual FORTRAN Storage 


! 0 ! 1 J 2 | 3 | 4 | 5 { 6 ! 7 • 8 | 

Actual C Storage 


! 1 

4 

7 ! 

: 2 

5 

8 : 

; s 

6 

9 : 

FORTRAN 

Storage 

(Columnwise) 

! 0 

1 

2 : 

! 3 

4 

5 ! 

: e 

7 

8 i 

C Storage 

(Rowwise) 


! 0 

3 

6 ! 

i 1 

4 

7 ! 

! 2 

5 

e : 


00S Storage (Columnwise) 


FIGURE 1: Array Storage Methods for FORTRAN and C 
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intuitively obvious. The biggest advantage is that it allows the 
programmer to overcome C’s inability to allow flexible array 
sising in subroutines in which an array is passed as an argument. 
In other words, when an array is received as an argument in a 
subroutine, it must be declared with dimension sises in the 
second and higher dimensions. For example, the three-dimensional 
double precision array "x" passed to a subroutine must be 
declared in that subroutine as follows: 

double x[] [2nd_Dimension_Sise] [3rd_Dimension_Size] ; . 

Since x is actually a pointer to a string of linearly stored 
memory, 2nd_DimensionJ5ise and 3rd_Dimension_Bise must be set at 
compile time to tell the program how to access the array 
elements. The first dimension sise need not be given. This 
allows the programmer who uses singly-dimensioned arrays 
flexibility to conceptually redimension arrays at execution time. 
It also keeps the programmer from creating arbitrarily huge 
multi-dimensional arrays in the hopes that such a monstrosity 
would take care of “all” situations. 

FORTRAN array indices normally start at one whereas the C 
convention is to start indeces at sero. In most cases, this 
difference in conventions is dealt with easily. However, svd has 
many array manipulations which require careful tracking of 

9 

indices. 

The biggest obstacle in the conversion was the “GOTO" 
statement. In most cases, these were easily replaced by “IF- 
THEN-ELSE" blocks. Other cases were more thought provoking. For 


4 


example, 'the subroutine "6NRM2*' was redone with two switch state- 
ments inside a while loop (see Appendix A). Elimination of the 
00T0 statement results in cleaner, structured, and more readable 
code. This is advantagious since structured code is more easily 
converted to other languages, such as Ada. 

Nevertheless, there is now has a workable C version of svd. 
The program was verified by testing matrices whose eigenvalues 
were already known (see Reference 2). The two test cases are as 
follows : 

Case 1 : 

! 7 3 1 ! 

! 3 4 2 ! 

! 1 2 3 ! 

whose eigenvalues are 9.433551, 3.419421, and 1.147028. 
Case 2: 

14 2 3 7! 

12 6 5 1! 

! 3 6 12 9 ! 

! 7 1 9 7 ! 

whose eigenvalues are 23.04466, 7.450091, 3.739112, and 
-3.233881. 

The svd program output for these two test cases are listed in 
Appendix 6. 
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9. The Vision Program 


Several changes were made to the original Vision program 
provided by Rice University. It has been reworked to use 
LinCom’s svd routine, matrix multiplier, matrix inverter, and 
other routines that do basic linear algebra. The program has 
also been converted to one-dimensional array storage using the 
same conventions as described in the svd section. Other changes 
were made to improve readability and to eliminate unnecessary 
memory allocation. 

Minor changes were made to the original program to allow 
interfacing with LinCom’s svd routine and matrix inverter. This 
temporarily gave LinCom a working version while the program was 
undergoing restructuring to conform to 008 standards. The 
original program arbitrarily set one-hundred as the maximum 
number of points that could be stored for a given object. This 
allowed allocation of 100 by 100 size arrays. So much memory was 
being allocated that the HP9000 Unix operating system killed 
execution of the program. The maximum was finally reset to 25 
so that the program could operate without a memory failure. This 
reduced memory allocation by at least an order of magnitude. 
Arbitrarily huge working matrices were being created for the sole 
purpose of interfacing with LINPACK linear algebra routines. 
Since LinCom’s linear algebra routines do not require huge 
working spaces, these temporary working matrices were eliminated 
in the 00S version. 

The program was changed to work with one-dimensional arrays. 


6 


This allowed direct usage of LinCom's linear algebra and avd 
routines. It also led to better memory management since 
arbitrarily huge temporary working matrices could be eliminated. 
Many arrays were shrinked dramatically since their sice was no 
longer dependent on the LINPACK linear algebra array conventions. 
For example, the array M XY" in many of the QIPC routines was 
reduced from 100 by 100 to 100 by 8. The array "SF" was reduced 
from 100 by 100 to 8 by 8 (see Reference 1). 

In the original program, many variables and arrays were 
allocated and never used. This may be due to the fact that many 
of the subprograms are quite similar in function and probably 
originated as copies of each other with some variables used and 
others not used. Nevertheless, variables and arrays that were 
originally declared and never used were eliminated. This greatly 
improved the memory management situation. 

Aesthetic changes were made to improve program readability. 
Loops were made to conform to regular C standards. Comments are 
currently being added to improve the understandability of the 
program. 

At its completion, the new one-dimensional version has been 
run and compared with results from the old version. The new 
version emulates the old version. The maximum number of object 
points has been reset to 100 without killing memory. 
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4 . 


Conclusion 


There is now a clean, working version of 'the Vision 
that can be integrated into the 00S. There is also 
routine written in the C language that could be used for 
programs . 


program 
an svd 
future 
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APPENDIX A 

Saaple FORTRAN Profraa With C Conversion 



hi. iq 1/ 1 1.< : ^ J J 9t< i snnr^' J ortren P?ae 1 


DOUBLE PRECISION FUNCTION SNRM2 tN ,S> . J NC X ' 

INTEGER NEXT 

DOUBLE PRECISION 5X < 1 ) . CUTLO , CUTHI , HI TEST , SUM , XMAX , ZERO , ONE 
DATA ZERO. ONE /0.0D0, 1.0D0/' 

DATA CUTLO, CUTHI / 6. 2320-11, 1.304D19 / 

] F ( N . GT. 0) GO TO 10 
SNR M2 = ZERO 
GO TO 300 

10 ASSIGN 30 TO NEXT 
SUM = ZERO 
NN = N * 1NCX 

I = 1 

20 60 TO NEXT, <30, 50, 70, 110) 

30 IF ( DABS (SX < I ) ) .GT. CUTLO) GO TO 85 
ASSIGN 50 TO NEXT 
XMAX = ZERO 

PHASE 1. SUM IS ZERO 

50 IF< 5 X < I ) . EQ. ZERO) GO TO 200 

'■ IF < DABS < SX < 1 ) ) .GT. CUTLO) GO TO 85 

PREPARE FOR PHASE 2. 

t ASSIGN 70 TO NEXT 

f GO TO 105 

PREPARE FOR PHASE 4. 

100 I = J 

ASSIGN 110 TO NEXT 
, SUM = (SUM / S X < 1 ) ) / SX(I ) 

105 X M A X = D ABS < S X < I ) ) 

GO TO 115 

PHASE 2. SUM IS SMALL. 

SCALE TO AVOID DESTRUCTIVE UNDERFLOW. 

'0 IF'.' DABS<5X(I)> .GT. CUTLO ) GO TO 75 

COMMON CODE FOR PHASES 2 AND 4. 

IN PHASE 4 SUM IS LARGE. SCALE TO AVOID OVERFLOW. 

10 I F < DABS < SX < I ) ) . LE. XMAX ) GO TO 115 

SUM = ONE + SUM * (XMAX / SX ( I ) ) **2 
‘ XMAX = DABS (SX ( I ) ) 

GO TO 200 

15 SUM = SUM + (SX ( I ) /XMAX) **2 
GO T 0 200 

PREPARE FOR PHASE 3. 

5 SUM = (SUM * XMAX) * XMAX 
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i C 

c 

,c 

c 


c 

c 

c 


95 


L 

200 


C 

c 

c 

c 

c 


300 


► 


F OF REAL OF D.F. SET HI TEST = CUT HI /N 
FOR COMPLEX SET HITE5T = CUTHl/(2+N) 

HI TEST = CUTHI/DPLE ( N ) 

PHASE 3. SUM IS MID-RANGE. NO SCALING. 


DO 95 J = I.NN.INCX 

IF (DADS (SX ( J ) ) .GE. HITEST) GO TO 100 
SUM = SUM + SX(J>**2 
SNR M2 = DSORT ( SUM ) 

GO TO 300 

CONTINUE 
1=1+ I NCX 

IF * I . LE. NN > GO TO 20 
END OF MAIN LOOP 


COMPUTE SQUARE ROOT AND ADJUST FOR SCALING 

SNR M2 = XMAX * DSORT (SUM) 

CONTINUE 

RETURN 

END 


I 
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♦ / 
* / 


Ana 2fc 16:40 1 R’E7 snrmC.c F«?ae J 


nnc 

# 1 nc 

jfdef 

* d r? t 
Idet 


] udc 
J ude 
inp 

l ne 
i ne 


stdi 
math 
PRE P 

PHASE 

PHASE 


o . h ; 

. h ; 

HASP CHECK 


/* 
/ * 
1 


UNIX STANDARD 
STANDARD NAT H 
/* Check 


1 

2 AND 4 


/* 

/* 


INPUT AND 
LIBRARY 

absolute value 
to see it >= cutlo 
Scan zero components 
Component nonzero and 


OUTPUT 

of SK Cl] 


* / 

* / 

- cutlo or 




>= ( cuthi / n ) 

*/ 

fdet i ne 

PHASE _3 

4 / * Component > cutlo 

*/ 

^def i ne 

LEVEL _.l 

5 'next calc' top level 

* / 

'def i ne 

LEVEL _2 

6 


def i ne 

LEVEL _3 

7 


define 

LEVEL_4 

8 


det i ne 

LEVEL_5 

9 


def i ne 

LEVEL_6 

10 


cable s n r m 2 * n , 

sx , incx 

) 


n t n : 

/> INPUT: 

Input vector dimension 

* / 

n t incx : 

/* INPUT: 

Increment of x 

* / 

oub 3 e ex C 3 ; 

| 

/* INPUT: 

Vector sx 

* / 

h t n e x t p h a s e ; 

/* 

Flaa indicating next jjhase phase of 


i 


algorithm 

* / 

t^t next_calc ; 

‘ 

/ * 

Flag indicating which sequential step 

algorithm 



level must execute 

■*/ 

• t i ; 

/ * 

Loop counter 

*-/ 

it j ; 

/ * 

Loop counter 

*/ 

“>t n j'Jncx : 

/ * 

Vector dimension times increment of x 

* / 

Duble xmax ; 

/ * 

Absolute value of array element 

* / 

pu.b 1 e hit es t ; 

/* 

cuthi / double ( n > 

★ / 

puble zero = 0. 

0 ; 

/* Machine dependent 'zero 

* / 

Dub 1 e one = 1.0 

n 

/* Machine dependent one 

+ / 

)ub 1 e cutlo = 4 

. 44 1 e- 1 6 ; 

/* Machine dependent 

*/ 

:*uble cut hi = 1 

. 304e 1 9 : 

/* Machine dependent 

+r / 

j>uble sum ; 


/* Algorithm parameter 

*/ 


v n 


0 ) return ( zero ) ; 


t_phe.se = PRE_PHASE_CHECK ; 
h't_calc = LEVEL_1 ; 

j»Ti = zero ; 

: x _ inc v = n * j. nc x ; 

|f= 0 ; 


•r v 


itch t. next _ q h as e ) { 

case PRE_PHASE_CHECK : 

if ‘ t a b s < sx C i 3 > > c ut 1 o ) 

next_.ca.lc = LEVEL JZ* ; 
break ; 
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j 

e 1 e e C 

next jDhase - PHASE 1 : 

m a x = zero ; 

•v 

case PHASE 1 : 

i t ( sx C i 3 « :ero ) C 

next_calc =- LEVEL 6 : 

break ; 

else it ( f abs ( sx C i 3 ) x cutlo ) C 
nex t_calc = LEVEL _2 : 
b r e a k ; 

j - 

el se C 

next j)hase - PHASE_2_AND_4 ; 
next__calc = LEVEL_4 ; 
break: ; 

j 

case PHASE _2_AND_4 : 

3 i ( -fabs ( 5X C i 3 ) > cutlo ) i 

next__calc = LEVEL_1 ; 
b r e a. k ; 


case PHASE _3 : 

1 t ( -f abs ( sx C i 3 ) < = x max > C 
next^calc = LEVEL_5 ; 
break: : 

j 

else i 

sum = one + sum * < xmax / sxCi3 > * ( -max / sx C i 3 > ; 

xmax = t abs ( sxCi3 ) ; 

next^calc = LEVEL_6 ; 
break ; 


de-fault s 

tpr i nt-f (stderr « "PROGRAM FAILED IN snmr2'~ switch next __phase /n u ) 
ex ltd) ; 
break: ; 

/* end switch ( next_phase ) */ 


itch ( next^calc ) C 
case LEVEL_1: 

sum = sum * x max * xmax ; 
case LEVEL_2 : 

hi test = cut hi / ( ( double ) ( n ) ) ; 
tor < j = i ; j < nji Jncx ; j += incx > i 
it( fabs ( exCj3 ) >= hi test ) C 

next.calc = LEVEL_3 ; 
break: ; 

sum = sum + sx C j 3 * sxCj3 ; 

j 

i + (. ne:it_calc != LEVEL_3 ) return ( sqrt < sum 


v 1 kr 

OS' ‘ 


fr . 


?.c 


QUAL 


-.TV 


Mua 


\ 


i 


lfr: 4 (? 198 ^ snrinr.c F'aae 3 


case 

LEVEL. 

) = j 

• 



nor t _ 

phase - 

PHASE , 3 ; 


s u m = 

( sum 

/ s x C i 3 ) / s 

ca?p 

LEVEL 

_4 : 



x max 

~ tabs ( 

£:■: C l 3 ) ; 

case 

LEVEL 

. 



sum - 

sum + 

< sx C i 3 / xma: 

case 

LEVEL 

__ t> : 



M 

II 

M 

+ l n c x 

: 


It < 1 

n __ 

l n c : : ) break 


/ x max ) 


el se C 

return ( ::ma;; * sqrt ( sum ) ) • 

1 . ■ 

default : 

tprint-f (stderr, “PROGRAM FAILED IN snmr 2 switch 'next calc'/n") 
1 t ( 1 ) ; “ 

break : 

/* end swi tch K next calc ) */ 


/* end for < ; ; ) */ 
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Appendix B 

Test Results of 8VD Algorithm in C Language 


t r at O', it n Jp 

C VERSION (if- SVP - OUTPUT FILE ] ) 


y MATRIX — betorr enteri no svcl 

7 . 0000000000 3 . 0000000000 1.0000000000 

3 . 0000000000 4 . 0000000000 2 . 0000000000 

j . 000000000U 2.0000000000 3.0000000000 


S MATRIX (Eigenvalues on diagonal) 

R . 4335510972 0.0000000000 0.0000000000 
0.0000000000 3.4194211565 0.0000000000 
0.0000000000 0.0000000000 1.1470277463 


U MATRIX (Le+t Singular Vectors) 

- 0.7881466619 0.557229756 2 0.2613605780 
- 0.5423013758 - 0.4278539749 - 0.7230838084 
- 0.2910910950 - 0.7116431514 0.6393881541 


V MATRIX (Right Singular Vectors) 

- 0 . 788 14668 19 0 . 5572297562 0 . 26 1 3805780 
- 0.5423013758 - 0.4278539749 - 0.7230838084 
- 0.2910910950 - 0.7116431514 0.6393981541 


U x U_TRANSPOSE 

1.0000000000 0.0000000000 0.0000000000 

0.0000000000 1.0000000000 0.0000000000 

0.0000000000 0.0000000000 1.0000000000 


V x V_TRAN5PGSE 

1.0000000000 0.0000000000 0.0000000000 

0.0000000000 1.0000000000 0.0000000000 

0.0000000000 0.0000000000 1.0000000000 


U x b x V_TRANSF'USE = X (as desired) 

“.0000000000 3.0000000000 1.0000000000 

3.0000000000 4.0000000000 2.0000000000 

1.0000000000 2.0000000000 3.0000000000 


ORIGINAL PAGE IS 

OF POOR QUALITY 



t c a t out i i 1 e 

C VERSION OF SVL> - OUTPUT FILF 

( c a a 2 ) 


X 

MATRIX — before enter 

mg s vd 


4 . 0000B00000 

0000000000 
o . 0000000000 
7 . 0000000000 

2.0000000000 
8. 0000000000 

5.0000000000 

1 . 0000000000 

3. 0006000000 
5.0000000006 
12.0000000000 
9. 0000000000 

7.0000000000 

1 . 0000000000 

9.0000000000 

7. 0000000000 

s 

MATRIX (Eigenvalues on diagonal) 


23. 04467254 1 1 
0. 0000000000 
0 . 0000000000 
0. 000G000000 

0.0000000000 

7.45O1012997 

0.0000000000 

0.0000000000 

0.0000000000 
0. 0000000000 
3. 7391178738 
0 . 0000000000 

0.0000000000 
0. 0000000000 
0. 0000000000 
3. 2338917147 

LI 

MATRIX (Lett Singular 

Vectors > 


-0.3456560386 
-0.31 17015538 
-0. 6883556-583 
-0.5563534392 

i 

-0.2872894068 
0.8489634413 
0. 1076069808 
-0. 4302/99831 

0. 6787287859 
0.3749567016 
-0. 6174607983 
0 . 1 32200 1119 

-0. 5807812035 
0. 2037417203 
-0 . 365 1 429691 
0. 6984648289 

V 

l 

MATRIX (Right Si ngul ar Vectors) 


-0. 3456580386 
-0. 31 17015538 
-0. 6883556583 
-0.5563534392 

-0. 2872994068 
0.8489634413 
0. 1076069808 
-0. 4302799831 

0. 6787287859 
0. 3749567016 
-0. 6174607983 
0. 1322001 119 

0. 5807812035 
-0.2037417203 
0. 3651429691 
-0.6984648289 


Ll x U_TRANSPOSE 



1 . 0000000000 
0. 000O000000 
0. 0000000000 
0. 0000000000 

0. 0800000000 
1 . 0000000000 
0. 0000000000 
0. 0000000000 

0. 0000000000 
0. 0000000000 
1 . 0000000000 
0. 0000000000 

0. 0000000000 
0. 0000000000 
0. 0000000000 
1 . 0000000000 


V x V_TRAN5P0SE 



1 . 0000000000 
0. 0000000000 
0. 0000000000 
0.0000000000 

0 . 0000000000 
1 . 0000000000 
0.0000000000 
0. 0000O00000 

0. 0000000000 
0. 0000000000 
1 . 0000000000 
0. 0000000000 

0. 0000000000 
0. 0000000000 
0. 0000000000 
1 . 0000000000 

(J 

;; S x V_TRANSF'QSE = X 

<a= desired- 1 


4. 0000000000 
2. 0000800000 

3.0000000000 

7 . 0000000000 

2. 0000000000 
8. 0000000000 

5. 0000000000 

1 . 0000000000 

3. 0000000000 
5. 0000000000 

12. 0000000000 

9. 0000000000 

7. 0000000000 

1 . 0000000000 

9. 0000000000 

7.0000000000 
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FUNCTIONAL CAMERA MODEL 


INPUTS: 

vehicle state from dynamics 
target state from dynamics 
target polygon model from object library 
vertices, no. of vertices 
faces, no. of faces 
connectivity of faces 
moment Invariants of faces 

AL60TITHM: 

• calculate actual target position In camera frame 

• If target not previously seen 

check If In range ( If not, status - ’not seen’ and exit ) 
check If In field of view 

( If not, status * ’not seen” and exit ) 
if in range, wait certail lag time before aquisition 

( if time in range is less than lag time, 
status * ’not seen* and exit ) 

• if target previously seen but moved out of range, 

lose sighting and exit 


***** OBJECT SEEN ***** 

• rotate object model from library to match vehicle dynamics 

• extract wireframe 

no. of faces 

definition of vertices of each face 
face connectivity 

***** ASSUMPTIONS: I) POLYGONAL OBJECT 

2) PERFECT WIREFRAME EXTRACTION 

• identify visible points of object (rrom wireframe) 

• calculate image points based on actual object position, 
coordinates of visible points in object frame, and lens 
focal length 




FUNCTIONAL CAMERA MODEL 


J 


OUTPUT: 

wireframe for MIAG Identification routine 
Image points for GIPC attitude determination and 
range & range rate determination 



CALCULATES ACTUAL 
VEHICLE AND TARGET 
DYNAMICS (“TRUTH") 


• CREATES WIREFRAME 
WHICH MODELS ACTUAL 
VEHICLE ATTITUDE 

• DEFINES IMAGE 
COORDINATES OF 
VISIBLE POINTS 


GIPC 

(ATTITUDE) 

♦ 

RANGE 


• DETERMINES 
ATTITUDE 
(GIPC) AND 
RANGE 
(BASED ON 
IMAGE 

COORDINATES) 


• CALCULATES 
ATTITUDE 
RATES AND 
RANGE RATES 


CONCEPTUAL FLOW DIAGRAM OF VISION MODELS 

IN OOS 















I 


C.Wf! |p i,.. 1,1. 

fvnctio-.,--} modi- 1 , c f ,, tl j T . ( 

ftfndards. Code 1 s resdv + o- 
3 ric J Lit 3 or. i nr o DOS. 


l n t o o ■■•■ft 


: t C' 

(J " ‘ • 

tire 

a n c 


" ,AC i dent i f i cat i on rout a nee have beer modified to cursor r- 
to UDS st anaards . Code is readv tor j n t< 
a no ] u = i or, into 005. 


.ea.ation test i nc: and 


fiCoiT' IS currently developing procedures to combine the 
MIA- identification information with the C-1PC attitude 
determination routine. Currently, the 6 1 PC reouires tr.at 
the image points from the two frames (before and after- 
rotation. be spec i f i cal 1 v paired . which it does, 
artificial 1 v W j thj n the software. However . Ml AC- D rovi das a 
coo'-esoondence mao between the wireframe 
oo.iert faces in the library. This map 
L ’ r -1 oue.lv identify image counts witf 

lT, -’dei . Thus. G I F'l knows which coin 
determine the attitude of the ooject. 

Aft-r" initial testing of the integrated 
random noise will be added to the vertices of the wireframe 
<?n_ L ~‘ tne image points in the camera model. This e msM 

noise will simulate error in wireframe extraction and image 
P o i rv-. idp.ti •l cat ion. 


4 H C p ? 

an j 

t he 

C 3 n jj #= 

«j ^ o r? 

Y p: 

“erpect 

to 

the 

t = it. h C~ s 


c a n 

v 2 a i on 

svst 
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ROBOTIC SPACE SIMULATION 


SIMULATION OF ROBOTIC SPACE OPERATIONS 

INTEGRATION OF YISION ALGORITHMS INTO AN 
ORBITAL OPERATIONS SIMULATION 


YASHYANT JANI, PhD 
WILLIAM L. OTHON 

LinCom CORPORATION 


RICIS Symposium 
15 October 1987 
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ROBOTIC SPACE SIMULATION 


AGENDA 


• OBJECTIVES 

• USE OF SIMULATION 

• INTEGRATION OF ROBOTICS / VISION ALGORITHMS 
INTO AN ORBITAL OPERATIONS SIMULATION 

• CURRENT EFFORT: INTEGRATION OF VISION 
ALGORITHMS FROM RICE UNIVERSITY WITH 
ORBITAL MANUVERING VEHICLE (OMV) MODEL 

• PROJECT STATUS 

• FUTURE EFFORT 


LinCoin 



ROBOTIC SPACE SIMULATION 



• DEVELOP A TESTBED FOR INTEGRATION OF 
ROBOTICS SUBSYSTEMS AND SPACE VEHICLES 
SIMULATION 

•• IMPLEMENT VISION/ROBOTICS AL60RITMS 
•• PERFORM SYSTEMS INTEGRATION ANALYSIS 

• STUDY OPERATIONAL ASPECTS OF ROBOTIC 
SPACE SYSTEMS AND MISSIONS 
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ROBOTIC SPACE SIMULATION 


'N 


USE OF SIMULATION 

• PRE-FLIGHT ANALYSIS 

•• DEFINITION OF MISSION REQUIREMENTS 
•• PERFORMANCE ENVELOPES 
•• FLIGHT ASSESSMENT 

• DEVELOPMENT OF MISSION SCENARIOS 

•• OPERATIONS 
•• PROCEDURES 

•• INTEGRATION OF SEVERAL VEHICLES AND 

SUBSYSTEMS INTO A COORDINATED SCENARIO 

• INTRODUCTION OF NEW VEHICLES / SUBSYSTEMS 

•• SPECIFICATION AND ANALYSIS 
•• SUBSYSTEMS REQUIREMENTS ANALYSIS 
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ROBOTIC SPACE SIMULATION 


INTEGRATION OF ROBOTICS/VISION ALGORITHMS 
INTO AN ORBITAL OPERATIONS SIMULATION 


• TESTBED REQUIREMENTS 

•• MODULARITY 
•• RAPID PROTOTYPING 
mm FIDELITY 

• ROBOTICS COMPONENTS IN OOS 

•• VISION 

•• REMOTE MANIPULATOR SYSTEM (RMS) 
•• AUTOMATED FLI6HT / EXPERT SYSTEMS 
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ROBOTIC SPACE SIMULATION 




CURRENT EFFORT 

INTEGRATION OF VISION ALGORTHMS 
WITH ORBITAL MANUVERING VEHICLE (OMV) MODEL 


• VISION ALGORITHMS FROM RICE UNIVERSITY 

•• OBJECT IDENTIFICATION 

••• MOMENT INVARIANT/ATTRIBUTED GRAPH (MIAG): 

•• ATTITUDE DETERMINATION 

• •• GENERALIZED IMAGE POINT CORRESPONDENCE (GIPC): 
••• MIAG EXTENSION (TENSORS) 

• OMV MODEL 

•• RIGID BODY DYNAMICS 

•• REACTION CONTROL SYSTEM (RCS) JETS 

•• OMV FLIGHT SOFTWARE (CONTROL SYSTEM. GUIDANCE. ETC) 

•• CAMERA MODEL 

• •• FOCAL LENGTH , RANGE . FIELD OF VIEW 

• •• EXTRACTION OF 2D WIREFRAME 

(LOW-LEVEL IMAGE PROCESSING) 


V*. 
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ROBOTIC SPACE SIMULATION 


CURRENT STATUS 

• ALGORITHMS IMPLEMENTATION COMPLETE 

•• CAMERA MODEL 

•• FUNCTIONAL WIREFRAME EXTRACTION 

•• MIAG IDENTIFICATION AND GIPC ATTITUDE 
DETERMINATION IN OOS 

• INTEGRATION TESTING IN PROGRESS 

•• MODULE INTERFACES COMPLETE 

•• NEW EVENT-DRIVEN OMV SEQUENCER GENERATED 

• TEST CASE DESCRIPTION 

•• THREE VEHICLES IN SAME ORBIT 

•• OMV WITH CAMERA IN LOWER ORBIT 

•• AS OMV APPROACHES TARGET, THE VISION 
ALGORITHMS WILL IDENTIFY OBJECT AND 
COMPUTE ATTITUDE AND ATTITUDE RATES 




LinCom 



ROBOTIC SPACE SIMULATION 




FUTURE EFFORT 


• PERFORMANCE ANALYSIS OF VISION ALGORITHMS 

•• INTRODUCE NOISE, ERROR. AND LAG TIME INTO WIREFRAME 
EXTRACTION ROUTINE 

• • ANALYZE RATE OF INPUT FROM VISION ALGORITHMS 

TO OMV FSW <1e PROCESSING SPEED REQUIRED 
FOR APPLICATIONS) 

•• ANALYZE ACCURACY REQUIREMENT FOR ORBITAL 
OPERATIONS 

• • EXPAND OBJECT LIBRARY 

• HARDWARE/SOFTWARE TESTING IN LABORATORY WITH 
PROCESSING TIME ANALYSIS 

• INTEGRATE OTHER VISION / ROBOTIC ALGORITHMS INTO 
OOS 

•• NEW ATTITUDE DETERMINATION ROUTINES 

• • RMS ALGORITHMS 

••• KINEMATICS 
••• SERVOS AND GYROS 

• INTEGRATE VISION/ROBOTICS ALGORITHMS WITH OTHER 
MODELS 

•• VISION ♦ RMS ♦ MMU = AUTONOMOUS ROBOT 
•• VISION ♦ SPACE STATION => TRAFFIC CONTROL 
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